Agile Service Development: A Rule-Based Method Engineering Approach1

Businesses may apply concepts of agility as a strategy to take up challenges in the rapidly changing business environment. Agility is defined as “the ability of a sensitive [organization] that exhibits flexibility to accommodate expected or unexpected changes rapidly, following the shortest time span, using economical, simple and quality instruments in a dynamic environment and applying updated prior knowledge and experience to learn from the internal and external environment” (Qumer en Henderson, 2007). This definition positioned in the context of agile service development asserts that an organization should be able to create or adapt a (business) service efficiently and effectively when changes occur in its environment. Agile development is not an alien concept in management and information systems research. It plays some role in existing work on situational method engineering in software product development literature (Olle et al, 1991; Kumar and Welke, 1992; Brinkkemper, 1996; Van de Weerd et al., 2006). Based on situational factors distilled from the project, meta-methods composed of outlines or more detailed procedures are selected and integrated into a coherent method appropriate for that specific situation (Brinkkemper, 1996). However, ‘situational’ is not synonymous to ‘agile’. For a method to become truly agile, changing situational factors also have to be linked (if required) to ‘run time’ changes in the method: quick responses to new situational information, and the installation of short feedback loops applying to the method. Utilizing the perspective of situationality, method fragments can be used to provide some degree of agility with respect to the project at hand. Regarding the assembly of method fragments, our approach follows the configuration process for situational method engineering as proposed by Brinkkemper (1996). However, our approach adds a second dimension of agility in operational execution. Changes in the environment will not always lead to changes in the executed method but can still influence the operational execution of a specific method fragment. To realize this, we propose a particular operationalization of the method engineering approach and process in terms of the selection process of method